Log | Metrics | Trace的联动方式探讨
可观测性三大支柱联动性不好
曾经询问已经使用可观测性相关软件的用户群体，对于他们来说最需什么功能的时候，很多用户的反馈都是Trace、Metrics、Log三者的联动性不好，是未来想完善可观测性的重要方向。
业界有很多专家都在研究这个问题，但是体验效果似乎仍然不好，这里谈下我们的理解，抛砖引玉，欢迎更多的探讨。
Log、Metrics、Trace三者集成难题
可观测性三大支柱集成难题主要因为以下几点
缺乏标准与协议
在opentelemetry没有成熟的2021之前，很多公司至少已经完成了统一日志的建立，Metrics的建立，Trace可能在最近两年逐步覆盖至所有业务系统，所以三大支柱在不同时期建设导致了三者没有办法按照日后成熟的opentelemetry协议进行很好的集成。
已有系统改造的成本大
将三者打通的工程工作量比较大，有些公司是因为不同供应商配合起来比较困难，有些公司是则因为之前建设系统的人员流动，导致系统被动陷入维护状态。
三大支柱的互动逻辑复杂
即便业务系统是新建立的，这个时候完全可以使用opentelmentry规范将三者数据在理论上做好集成的准备，但是三者的流畅的集成，仍然面临着不少的问题。
-
完美用户体验设计界面非常难：用户排障过程是没有标准化的，也就意味着用户在看到某现象的时候，比如某个指标异常，可能接下来想看当时节点的日志，也可能想看当时的trace数据，这就导致界面要灵活的设计非常复杂。国外datadog的解决方案就是将页面设计成了可观测性数据搜索平台，用户可以添加很多的过滤条件对数据进行过滤，从而快速找到相关数据。国内如果也这样做会导致用户一上来看到如此复杂的界面，不知道该如何着手去排查问题，很难落地。
-
不同背景用户述求不一样：可观测性数据是海量低价值的数据，界面上应该先呈现什么样有价值的数据很难权衡。不同的部门用户有自己的习惯，开发者最习惯看的是日志，不管是bug，还是系统故障，第一诉求就是看日志，因为这是开发者长期职业过程中形成的习惯，SRE可能会想先了解指标，并且根据自己的经验，配置不同的大盘，然后能够根据不同大盘一层层剖析。那能不能干脆分不同页面进行设计，比如有日志首页，指标首页，追踪首页等，现在很多公司确实就是这么做的，但是导致的问题也就是三者虽然在技术上能打通，但是使用体验上仍是割裂的。
-
在一定规模下，可观测性数据查询性能差：可观测性数据的海量低价值特性，导致查询数据很慢，大家一定碰到过查询ELK的日志转个几秒才出来，追踪也是转个几秒出来，Prometheus server还可能由于维度问题，不断重启等现象。在这种场景下，用户在探索三者数据的时候是非常崩溃的，体验非常不好。即便有天才的设计师完成了三大支柱很好的界面交互，但是这缓慢的查询体验会让完美界面交互的价值降到无。
Kindling-Originx提供了不一样的思路
一种思路是加大资源投入，如果任何查询慢，就通过分布式扩资源的方式解决，然后期望业界有天才的设计师能够设计完美符合大部分用户习惯的界面交互设计。
Kindling-Originx认为可能还有另外一种方式可以解决此三者难以集成的问题。
Kindling-OriginX 提供了标准化的排障方式简化了用户体验设计
在排障过程中，什么时候该看什么数据，已经根据专家经验在界面流程当中设计好了，排障的特异化需求就能被固化并同步下来。
Kindling-OriginX 提供了自动化智能化查询分析功能
如果只有文档化的标准排障理论，没有 通过机器自动化智能化分析故障，并将标准化排障过程当中所需的数据自动化关联查询出来，完全依赖人去落地标准化排障是非常难的。
Kindling-OrginX 智能化给出结论
Kindling-Originx报告给出了故障根因结论，但并不是仅仅给出了故障根因而已，而是将故障的完整推导过程所需的log、metrics、trace都查询好了，并集成至故障报告当中，这样就不是临时再去查询log、metrics、trace。用户如果怀疑故障根因分析得不对，可以一次性针对故障所需数据做出结论性判断，再也不用因为某些数据查询慢而打断思路。
Kindling-OriginX 联动方式实例
在 Kindling-OriginX 的故障根因报告中，已将 Log、Metrics、Trace 数据相关联后进行集成，并完成了故障根因的推导分析，具体可参见下面各类数据的实例。
链路数据Trace
Trace数据中给出了本地调用的链路相关数据，以及各种耗时信息与历史基线的对比情况。
故障根因结论
故障根因是故障报告的结论，是结合报告各类数据综合分析后得到的最终结果。
故障节点分析及相关日志
Kindling-OriginX 会抽取出相关联时间段内的关键日志数据，以供查阅。
各类关联指标数据
Kindling-OriginX 自动化关联了与故障相关的各类指标数据，如接口具体的执行耗时情况，runq、网络质量指标等数据， 既是推导的过程依据，又可方便进行统一的二次分析。
